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Human exploration missions that reach destinations beyond low Earth orbit, such as 
Mars, will present significant new challenges to crew health management. For the medical 
system, lack of consumable resupply, evacuation opportunities, and real-time ground 
support are key drivers toward greater autonomy. Recognition of the limited mission and 
vehicle resources available to carry out exploration missions motivates the Exploration 
Medical Capability (ExMC) Element’s approach to enabling the necessary autonomy. The 
Element’s work must integrate with the overall exploration mission and vehicle design 
efforts to successfully provide exploration medical capabilities. ExMC is applying systems 
engineering principles and practices to accomplish its goals. This paper discusses the 
structured and integrative approach that is guiding the medical system technical 
development. Assumptions for the required levels of care on exploration missions, medical 
system goals, and a Concept of Operations are early products that capture and clarify 
stakeholder expectations. Model-Based Systems Engineering techniques are then applied to 
define medical system behavior and architecture. Interfaces to other flight and ground 
systems, and within the medical system are identified and defined. Initial requirements and 
traceability are established, which sets the stage for identification of future technology 
development needs. An early approach for verification and validation, taking advantage of 
terrestrial and near-Earth exploration system analogs, is also defined to further guide 
system planning and development. 


Nomenclature 
ConOps = Concept of Operations 
ExMC = Exploration Medical Capabilities 
MBSE = Model-Based Systems Engineering 
NASA = National Aeronautics and Space Administration 
SysML = Systems Modeling Language 


I. Introduction 


XPLORATION missions beyond low earth orbit bring opportunities for enhancing humanity’s capabilities. The 
missions also bring challenges in the development of those capabilities. A driving case of a human mission to 
Mars will be longer than human space missions to date, and also will lack the medical evacuation, real-time 
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communication, and resupply more readily available for current low-Earth orbit operations. In addition, predicting 
the exact medical conditions for which to plan will not be possible. Therefore, an exploration medical system must 
provide flexible capabilities to support the care of crewmembers with conditions that were not considered 
specifically in advance. Medical technologies to be considered in exploration designs will continue to rapidly evolve 
for the foreseeable future, so the design framework must allow for new technologies. Limited flight resources such 
as mass, power, volume, and data, are constraints requiring the medical system to be viewed as an integrated part of 
flight system development for exploration. A systems engineering approach is required to meet the exploration crew 
health management needs within opposing constraints. The Exploration Medical Capability (ExMC) element of 
NASA’s Human Research Program is undertaking these systems engineering activities [1, 2]. 


II. Systems Engineering Approach for the Medical System 


A. Systems Engineering Management Approach 

There are many ways to approach the practice of systems engineering principles. As the ExMC Systems 
Engineering (SE) team was established, a Systems Engineering Management Plan, tailored from the NASA Systems 
Engineering Handbook [3], was developed to capture context, approach and execution information. 

The mission of the ExMC SE team is to “Define, develop, validate, and manage the technical system design 
needed to implement exploration medical capabilities for Mars and test the design in a progression of proving 
grounds.” During the SE team’s formulation in 2016, a customized version of a Needs, Approach, Benefits, 
Challenges (NABC) assessment [4] was developed to communicate the vision for the SE team and its stakeholders. 
One noteworthy customization was for the “C” portion of the exercise, in which the team addressed “culture” as a 
specific challenge. 

ExMC SE activities will meet the following NEED: Develop the system technical foundation. Specifically, the team 
will: 
* Develop Concept of Operations material 
* Capture stakeholder expectations 
* Define and manage requirements 
* Capture and share system designs 
¢ Identify and manage cross-disciplinary interfaces 
¢ Plan and execute system V&V 
¢ Inform system development decisions from scientific and technical perspectives 
* Identify technology development and research needs 
The ExMC SE team will take this APPROACH: Apply structured and integrative science and engineering. 
Specifically, the team will: 
¢ Use a structured and disciplined technical approach to develop a medical system addressing medical, behavioral 
health, human factors, physiological performance, and task performance needs to ensure crew health and 
performance 
* Enable effective coordination and integration with exploration mission engineering, operational, and technology 
development efforts 
The ExMC SE team will provide the BENEFIT: Increase relevancy to exploration system maturation. Specifically, 
the team will: 
* Communicate in the same language as engineering and operations communities with respect to system design 
¢ Provide regular and transparent communication to maintain programmatic and stakeholder situational awareness 
and provide insight into the medical system development 
* Develop and foster shared mental models within and external to crew health and performance community 
The ExMC SE team will operate with the following CULTURE: Be open, unbiased, learning, and serving. 
Specifically, the team will: 
* Develop relationships across disciplines and Centers to build trust and enable teamwork 
¢ Enhance visibility and opportunities for influence on concurrent activities of related groups that otherwise would 
not happen 
¢ Foster learning of SE principles and practices 
* Be both responsive to and anticipatory of stakeholder needs, keeping in mind stakeholders may be from 
anywhere in an organizational chart 

As NASA’s exploration plans develop, the ExMC SE work will allow early integration of medical 

considerations into the designs of missions throughout exploration phases shown in Figure 1, from reference [5]. 
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The team is using the Deep Space Transport Mars verification mission, shown in Phase 2 and currently described as 
a round-trip human Mars mission without a surface landing, as its current focus of activities. 
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Figure 1. Current NASA plans for exploration. 


B. Application of Model-Based Systems Engineering 

ExMC is utilizing Model-Based Systems Engineering (MBSE) to support medical system definition and analyses 
that will inform research activity needs and prioritization. MBSE is an engineering approach used to model the life 
cycle activities of a project, and provides an alternative to the more traditional document-based approach to 
engineering. Using a traditional document-based approach to systems engineering can result in cost increases, raise 
technical risk and create information silos among teams. Diverging from the document-based approach will offer 
significant savings through avoidance of maintaining disparate documentation that runs the risk of becoming 
obsolete or inconsistent with evolving project goals. The ExMC system engineering team’s use of MBSE, applying 
the System Modeling Language (SysML) and supporting MBSE tools, is enabling technical communication through 
the use of shared mental models of the medical system, consistent notation and integrated data sets. These system 
models will be integral for successful integration of the medical system with exploration vehicles and system 
verification and validation using terrestrial analogs and precursor exploration missions. 

The use of MBSE tools helps to streamline communication, content, and system design across the ExMC SE 
team that works in different geographic locations and addresses a variety of technical discplines. The SE team’s 
tools are being designed and selected to support meta-data exchange as integration points to crew health, crew 
performance, and other vehicle system and subsystem models are identified. MBSE is improving shared 
understanding of system needs and schedules between stakeholders, provides a common language for analysis, and 
will help to facilitate identification of risks. SysML is being utilized here to provide a controlled common model of 
the medical system and requirements definition activities. SysML provides diagrams as views into the underlying 
model, and a subset of examples related to the medical system will be described in this paper. 


C. Initial Process Overview 

The scope of developing an exploration medical system is a large one. At this early stage, the ExMC Systems 
Engineering team activities must focus on establishing highly valuable technical products and an infrastructure to 
support the continued development of additional products later in the medical system life cycle. Figure 2 shows the 
initial process the systems engineering team is following based on systems engineering activities typical in early 
design phases [6, 3]. 
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Figure 2. Initial activities for exploration medical system development. 


The team began its efforts with existing information provided in NASA Standards specifically focused on crew 
health and performance. Additionally, the team defined its set of stakeholders and developed goals for the 
exploration medical system. In the absence of an exploration program, assumptions were made and documented, and 
are now being updated based on NASA’s current exploration plans [5]. The team captured system goals, 
assumptions, and operational scenarios in a Concept of Operations (ConOps). The ConOps scenarios were next 
modeled and extended in SysML to support a functional decomposition analysis. This body of work allows the team 
to progress to writing medical system functional requirements. As the behavioral content matured, system 
architecture development began, and will continue to evolve with the generation of requirements. 

Once system requirements and an architecture is in place, subsystem architectures will be developed, and 
requirement allocations will be made. Characterizations of the system options will be performed, including 
evaluations of important design properties such as mass, power, volume, data needs, medical equipment layout, and 
risk estimations. The SE team is setting up its set of tools to inform trade study analyses, and identify areas of low 
maturity that would benefit from design, build, and evaluation activities as part of early exploration missions or 
ground-based analogs. 


III. Medical System Stakeholder Expectations 


A. NASA Standards Interpretation: Level of Care Assumptions 

NASA medical care standards establish requirements for providing health and medical programs for 
crewmembers during all phases of a mission. These requirements are intended to prevent or mitigate negative health 
consequences of long-duration spaceflight, thereby optimizing crew health and performance over the course of the 
mission. Current standards are documented in the two volumes of the NASA-STD-3001 Space Flight Human- 
System Standard document, established by the Office of the Chief Health and Medical Officer. Their purpose is to 
provide uniform technical standards for the design, selection, and application of medical hardware, software, 
processes, procedures, practices, and methods for human-rated systems. NASA-STD-3001 Vol. 1 [7] identifies five 
levels of care for human spaceflight, listed in Table 1. Each level has several components listed that illustrate the 
type of medical care expected. Interpretation of these components and the associated amount and type of care 
required at each level is dependent upon several factors, including the duration of the mission, accepted amount of 
medical risk, the level of training of the healthcare provider, terrestrial medical standards, technology and resources 
available for use in the flight environment, and the time it would take to to get an ill or injured crewmember to a 
definitive care location. 


Level of Care | Capability 
I Space Motion Sickness, Basic Life Support, First Aid, Private Audio, Anaphylaxis Response 
Il Level I + Clinical Diagnostics, Ambulatory Care, Private Video, Private Telemedicine 
Il Level II + Limited Advanced Life Support, Trauma Care, Limited Dental Care 
IV Level HI + Medical Imaging, Sustainable Advanced Life Support, Limited Surgical, Dental 
Care 
Vv Level IV + Autonomous Advanced Life Support and Ambulatory Care, Basic Surgical Care 
Table 1. Levels of Care (Reference [7], V2, Rev A, Table 13). 
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ExMC has expanded the context of the levels of care and components to assist the multidisciplinary ExMC team 
with consistent interpretation as they approach future work [8]. This supplemental information includes definitions 
for each component of care and example actions that describe the type of capabilities that coincide with the 
definition. This interpretation is necessary in order to fully and systematically define the capabilities required for 
each level of care in order to define the medical requirements and plan for infrastructure needed for medical systems 
of future exploration missions, such as one to Mars. Table 2 gives an example of a definition and capabilities 
associated with Limited Advanced Life Support, a component listed in Level of Care 3. 


Capability Definition Example Actions “*” indicates augmentation of action from lower level of care 
Limited Diagnosis and initial | - Control over body positioning and workspace 
Advanced treatment for an Airway: 
Life Support | emergent medical - Reposition airway, insert airway adjuncts “and supraglottic airways 
(ALS) event. - Clear obstructed airway with manual maneuvers 
- *Suction airway 

Resources to Breathing: 

support medical - Provide breaths using “manual means 

decision making - *Provide and titrate oxygen via noninvasive/invasive means 

using data obtained | Cjreulation: 


from telemedicine, 
limited physical 
exam, vital signs, 
and clinical 
diagnostics. 


- Control bleeding using direct pressure 

- Provide chest compressions 

- *Defibrillate using automated device 

- Measure, record, and trend vital signs (heart rate & rhythm, respiratory 
rate, blood pressure, temperature, oxygen saturation) 


Table 2. Example of an expanded component definition within a Level of Care definition 


Clearly defined levels of care, and what capabilities are included in each, provides a common starting point for 
discussing the medical system; not just for use within the ExMC team but also for communicating with the project’s 
many stakeholders. 


B. Stakeholder Needs and System Goals 
A thorough understanding of stakeholders’ needs and expectations is vitally important and serves as the 


foundation for other systems engineering activities and products. This process provides ExMC systems engineers 
with a way to ensure key stakeholders are in agreement and that the realized system will meet expectations. 
Reaching consensus early in the project on things such as high level capabilities, system characteristics, behaviors 
and performance is important because it shapes customer expectations, bounds the problem/solution space and 
establishes criteria to determine if the right system is built and delivered. 

ExMC has identified a core set of driving stakeholders that are important in understanding how the system will 
be used in its operational environment. Driving stakeholders include the Office of the Chief Health and Medical 
Officer (OCHMO) Health and Medical Technical Authority (HMTA), the Human Research Program (HRP), the 
Astronaut Office, the Medical Operations community, the Human System Risk Board (HSRB) and international 
partner representation in coordination with the Crew Health and Preformance (CH&P) System Maturation Team 
(SMT), under the Human Exploration and Operations Mission Directorate (HEOMD). Refer to Figure 3 to see 
relationships between the driving stakeholders and ExMC. Red numbered text indicates primary types of outputs 
from ExMC. 
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Figure 3. ExMC interactions with driving stakeholders. 


A set of system goals has been developed to provide a foundation for exploration medical system development. 
They are based on stakeholder expectations and constraints levied or imposed on the medical system. These goals 
influence technical measures commonly used for insight into performance of the technical solution, and establish the 
basis for high-level requirements and quality attributes of the medical system. 


Comprehensive Health Management 
Provide comprehensive health management capabilities to enable mission task performance and mission success. 

Recognizing the extended duration and distance from Earth during exploration missions, in-mission care 
capabilities must span prevention, diagnosis, treatment, and long term management for both clinical and well-being 
aspects of health. These capabilities will use resources (e.g., skillsets, software, hardware, medication) to prepare for 
and execute planned and unplanned medical operations, pharmacy operations, personalized medicine, training, 
resource management, ethics considerations, data management, and risk estimation. 

Crew Autonomy 
Enable crew autonomy in medical task execution and decision-making. 

Although ground medical support will remain an important part of medical care, the autonomous care model for 
exploration requires flight surgeons and other support staff to fill a consultant role. The mission physician astronaut 
will serve as director of care during real-time medical events and will be the primary source for in-mission medical 
decision-making. To support the physician astronaut this medical care paradigm requires comprehensive vehicle 
capabilities and resources in the form of onboard medical references, smart diagnostics, and decision support 
systems. 
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Continual Information Application and Learning 
Support medical system knowledge augmentation over the mission lifetime. 

It is desired to be able to use knowledge gained both in-mission and on the ground to update medical system 
elements, such as task training, decision support, and models for estimation and prediction of crew health and 
system status. 

System Flexibility and Extensibility 
Balance conflicting needs for medical system resource conservation (in design and in mission) and medical system 
operations. 

Flexibility and extensibility are needed because the in-mission resources will be constrained and because of the 
inability to definitively predict all medical conditions that will occur during the mission. Medical flexibility helps 
identify the broadest use opportunities for a limited resource set relevant for clinical needs. Extensibility addresses 
conditions and situations outside of the target design conditions. 

Medical, Vehicle, and Mission Systems Integration 
Integrate hardware, software, human, and operational aspects of the medical system with the mission and vehicle 
design. 

The in-mission medical system should be viewed as a component of the overall integrated vehicle system. When 
allowed and appropriate, medical data and information should be shared with other vehicle system components, and 
vice versa. 

Crew and the Medical System Integration 
Design the medical system to fit the needs, abilities, and limitations of the crew. 

A well-designed medical system minimizes training time and operations complexity and lowers mission medical 
risk. It accounts for the various modes of data entry, input devices, computing platforms, and user preferences 
employed on the vehicle and incorporates human system integration and human factors guidelines to reduce the 
cognitive and physical workload while using the medical system. A well-designed, usable medical system is easy to 
learn and operate, keeps the user informed on what is going on, reduces the number of errors and makes them easy 
to recover from, and assists in the timely completion of tasks. The expectation is that unobtrusive automated and 
manual processes are available to support crew activities. 

Ground Awareness 
Maintain ground situation awareness of crew health and medical system status as flight communication constraints 
permit. 

The ground support system will continue to be informed on the state of the crew and medical system to assess 
impacts to the mission goals and objectives and to provide support as needed. 

Defining the medical system goals enabled fruitful discussions with stakeholders at an early stage, and provided 
initial insight into the functions the medical system will need to provide. 


C. Concept of Operations 

The Medical System Concept of Operations for Mars Exploration Missions outlines the capabilities required to 
ensure appropriate medical care for the crew of a highly autonomous future NASA mission to Mars. This Concept of 
Operations (ConOps) document decomposes the overall mission into a series of mission phases, starting with Earth- 
based launch and concluding with Earth entry, descent, and landing. When complete, the ConOps will illustrate the 
potential medical capabilities for each mission phase through sets of medical scenarios, involving the crew, onboard 
equipment and tools, and ground personnel. Each scenario consists of a context description (e.g. dental exam), a 
highlighted functionality list, assumptions, an activity flow chart (see Figure 4), and a narrative text to provide 
context for the flowchart. Collectively, these scenarios enable ExMC to use MBSE tools for planning, designing, 
and prototyping an integrating a medical system for preventing, diagnosing, treating, and managing long-term the 
health and medical risks inherent to human exploration missions to Mars. 

Initial development of the ConOps is focusing on the Mars transit (cruise to Mars) phase, which has been 
organized initially into twelve scenarios, each defined by the nature of the activity, who is involved with the activity, 
and whether the acivity is planned or unplanned. For example, the following activity flowchart represents a planned 
(routine) dental exam involving a patient, a caregiver, the medical system, the ground system, and the vehicle 
system: 
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Phase: Transit 
Context: Dental Exam 


Scenario: IVA — Planned — Directed Care - Autonomous 


Initiate Encounter 
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The narrative text associated with the highlighted boxes is provided below as an example: 


Perform History 
Collection 


MS takes history 
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Perform Vitals 
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MS records and 
reports information 


Figure 4. Flow chart of activities in the dental exam scenario. 
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The medical system sends an alert to the physician astronaut and patient that a scheduled dental 
exam will start in ten minutes. The patient heads over to the medical bay and picks up a display, 
which uses biometric analysis to identify him and grants him access to his health record in the 
medical system. 
The medical system starts the appointment by prompting him to review his health record 
documentation for accuracy and update if needed. Areas of review include: past medical, 
surgical, and dental treatment history, allergies, current medications, and then a series of 
questions to complete a review of systems. It then uses biosensors to collect vital signs from the 
patient, such as blood pressure, heart rate, oxygen saturation, temperature, and respiratory rate. 
These are all automatically saved to his health record and displayed back to him. 


Each scenario is intended to demonstrate a set of functions. For the dental exam scenario, those funtions are: 
a) prompt the initiation of an activity per the crewmember's schedule 
b) prompt the initiation of an activity based on a protocol 


c) retrieve information from the patient 


d) guide a crewmember during an activity 
e) interpret information gathered during an activity 
f) provide varying levels of support to a crewmember 


While the Mars Transit phases content currently comprises 12 scenarios, additional scenarios may be added as 
needed, and other phases scenarios will vary in quantity, subject, and functionality. 
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IV. Medical System Behavior Descriptions 


A. Medical System, Crew, and Flight System Activities 

Flow charts from the ConOps are analyzed and translated into Activity Diagrams in a SysML model. An 
example Activity Diagram of the first portion of the Dental Exam scenario is shown in Figure 5. This clarifies the 
activities expected to be performed by the medical system, each crewmember (whether in a patient or caregiver 
role), and the other flight or ground systems. Each horizontal swimlane represents actions performed by either the 
Patient, Caregiver, or Medical System. For example, one action “Prompts CG and PT to initiate encounter,” under 
the “Initiate Encounter” box defined in the ConOps flow chart (Figure 4) can now be understood to be performed by 
the Medical System, and the other action “Activates support from MS”, will be performed by the Patient. The 
“Prompts CG and PT to initiate encounter” and “Conducts vitals collection on PT” actions represented in the 
Medical System swimlane will be discussed in other SysML diagrams throughout this paper. 
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Figure 5. Portion of the dental exam scenario Activity Diagram. 


B. Behavioral Interface Identification and Description 

The ConOps scenarios are also captured as Sequence Diagrams in the SysML model. While the Activity 
Diagrams help to capture the flow of activities, Sequence Diagrams illuminate interactions among participants in the 
scenarios. Each ConOps scenario was deconstructed in Sequence Diagrams to identify interactions between the 
medical system, crewmembers (in patient or caregiver role), the exploration vehicle, and the ground system. This 
work helps to define functions the medical system must provide, flow of data and physical objects, and interfaces 
the medical system must provide to crewmembers and other systems. These products support functional 
decompositions for the medical system, crew, vehicle and ground systems, and the subsequent development of 
medical system and other system requirements. 

Using the Dental Exam scenario as an example, Figure 6 highlights a few of the interactions that will occur 
between participants. The participants are shown as boxes at the top of the diagram, and interactions, or messages, 
are represented by the horizontal lines. The naming convention used in the messages abbreviates who the message is 
to (ms for Medical System in message 8), who the message content is from (Pt for Patient in message 8), and the 
type of information conveyed (VitalsInfo in message 8). 

At the point in the scenario when message 8 occurs, the exam has been initiated, the patient has entered their 
updates to the history, and the medical system is collecting the vitals information directly from the patient. During 
the functional decomposition, this activity is abstracted from the diagram and from the perspective of the medical 
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system the action could be described as ‘Obtains vitals info from patient’. Later in the model, this interface 
identification will turn into a requirement for a subsystem that is capable of obtaining vitals information directly 
from the patient. Message 9 shows that the medical system records and reports information. This message is unique 
in that it is not an interaction, but rather indicative of an autonomous activity the medical system should be able to 
perform. The physician then arrives and conducts the physical exam. Message 13 highlights the need for the medical 
system to accept inputs from the caregiver documenting the physical exam. The sequence diagram is a clear 
visualization of the interactions between actors in the system, and helps to identify additional functions and system 
interfaces that will receive futher detail in the requirements definition phase of the model design. 
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Figure 6. Portion of the dental exam scenario Sequence Diagram. 


C. Functional Decomposition 

The system behavioral content was analyzed and grouped into functions. A function typically starts with a verb 
and describes what the system does. These functions were further decomposed until each activity was mapped to a 
function. Information in this functional decomposition provides a more complete representation of the medical 
system “problem space”. At the highest level, these functions aid in the development of the medial system 
architecture, which is the first foray into the “solution space”. 

Figure 7 shows how the medical system functions are broken into 8 sub-functions. One of these sub-functions is 
“Inform decisions on crew health actions”. 
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. Figure 7. High-level medical system functional decomposition. 


Figure 8 further breaks-down this sub-function and shows the mapping of the activities to this sub-function. The 
earlier mentioned activity “Prompts CG and PT to initiate encounter” maps to the function “Prompt crew” which is a 
sub-function of “Inform decisions on crew health actions”. 


: ity» 
perform_conference 'e_prescription_to_CM 


Figure 8. Sample scenario activities grouped under “Inform decisions on crew health actions”. 


V. Medical System Architecture Description 


A draft system context and architecture was developed based on the needs, goals, and behaviors of the system. 
As requirements are written, the architecture will be refined, including defining lower levels of detail and eventually 
relating to physical components. Figure 9 presents a context architectural view centered on the Medical System as 
part of the overall vehicle Flight System. The focus of the initial ExMC MBSE activity is on the Medical System 
that will support crew for Deep Space Transportation missions (refer to Figure 1). The Flight System, Ground 
System, Caregiver, and Patient are included as high level components of this context view because the Medical 
System will have important interactions with each. For example, defining the required medical skillset of the 
Caregiver is important for understanding the necessary Medical System support. 

Within the Flight System, traditional functional flight systems such as Structures and Avionics appear as the 
bottom row of blocks to provide context and awareness of future interfaces with those subsystems. For example, 
certain vehicle consumables, such as water and oxygen, will be required for medical purposes, but are not within the 
scope of the Medical System; they will likely be provided by the Environemental Control and Life Support System 
(ECLSS). 
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Figure 9. High-level medical system architecture and context. 


Within the Crew Health and Performance (CHP) System, there are also blocks for the natural and induced flight 
environment protection not covered by other vehicle subsystems (e.g., radiation monitoring or protection not 
incorporated in the vehicle structure), and characterization of mission task support functions, which includes in- 
mission training for the crew and user interfaces for each device, including any device-specific procedure guidance, 
and user interfaces for the Crew Health & Performance Data System. A Health & Wellness System block is noted 
within the CHP System as it captures necessary crew support sytems such as the food supply, exercise system, and 
behavioral health support. Interfaces from devices in these categories to the CHP Data System are currently being 
identified. These devices are items that are likely referenced but not controlled by the Medical System architecture 
element. 

The Medical System is characterized by three high level containing constructs: 

Crew Health & Performance Data System 

Within the scope of ExMC, the Crew Health & Performance Data System (CHPDS) is a core component of the 
overall Crew Health & Performance System (CHP). It is responsible for providing information and data to crew 
members via user interfaces. The data system is planned to collect all medically relevant information from disparate 
sources (environmental details, biosensors, exercise regimens, medications, lab diagnostics, and electronic medical 
records). These data are available for consultation onboard the spacecraft, and are also transmitted to the ground for 
additional analysis. Data privacy and confidentiality will be handled consistently with US laws and policies. 

Besides data collection and storage, the data system provides data to other on-board systems as-needed through 
software interfaces. Another planned functionality of the system is to enable decision support capability by tracking 
and trending biometric details over time, and by implementing analytical algorithms that augment the knowledge of 
the decision-making crewmember. This is important for deep space missions where operations demand crew 
autonomy. The system is anticipated to afford such analytic capabilities by combining information on the crew and 
the vehicle’s environment. Some examples of the information that may be analyzed include medical image 
interpretation, biomedical metrics identification, medical history notification, exercise performance review and 
vehicle environment data review. 
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Medical Devices 
This block categorizes devices that may be implemented to perform medical tasks or procedures. These devices 

are defined by their interface(s) with one or more other systems in the form of power, data (physiological and 
laboratory), vacuum, or consumables. Devices that exist in this category may include biosensors, which collect and 
transmit physiological data, and pharmaceutical hardware, which aid in the dispensing of medication. Note that in 
the early stage design process and within the context of model-based system development this will typically be a 
large list of items where, for a given system architecture option, a subset of items is selected for incorporation into 
the habitat design. This “instancing” of items for the purpose of characterizing a particular design provides a means 
to characterize and formally track design trades. 
Medical Supplies 

This block categorizes items used for medical care that are consumable, do not require power, or do not generate 
data. These items also lack interfaces to other systems for vacuum or consumables. For example, this block includes 
reusable items, such as scissors, splints, and sharps containers, and single-use items, such as masks, hand sanitizer, 
gloves, waterproof tape, catheters, instant ice, bandages, needles, and gauze. These items are tracked here to define 
an understanding of the quantities required. 


VI. Initial Traceability Development 


The ability to see relations between model elements is an important feature enabled by a strongly architected 
model-based approach. Example SysML relationships are “allocate”, “derive”, “verify”, and “satisfy”. Figure 10 
shows the allocation of two activities (orange) to the blocks (brown), or elements of the system, responsible for 
performing that activity. The use of an activities allocation matrix (Figure 10) is an excellent means of observing the 
often large number of allocations and interrelationships. In this figure, a subset of activities (rows) and blocks 
(columns) are shown. The intersections of activities and blocks populated with an upward right arrow indicates an 
allocation of the activity to the block. 
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Figure 10. Allocation of activities to architecture elements. 
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Figure 11. Traceability matrix for allocated activities. 


Blocks with appropriate behaviors are the model elements that satisfy program requirements. Requirement 
satisfaction will be tracked via a requirements allocation matrix, similar to the activity allocation matrix in Figure 
11. The “satisfy” relationship, analogous to the “allocate” relationship, enables the traceability. Establishing the 
ability for requirements and subsequent solution options to be traced to content in key documents, such as NASA- 
Standard 3001 [7] and the ConOps, will also lead to the identification of technology development needs. 
Relationships of requirements to rationales and reference information will also be tracked in the EXMC SysML 
model. 


VII. Verification and Validation Approach 


The ExMC approach for verification and validation plans is to take advantage of terrestrial analogs and near-Earth 
exploration system maturation. A series of stepping-stone medical system developments aboard ISS, cis-lunar 
missions, and flights beyond cis-lunar space will be utilized for maturation of medical system products. These 
developments will provide an opportunity to interface with vehicle design groups, especially those also utilizing the 
MBSE approach, and further streamline processes across NASA mission development teams. Development of the 
medical system concepts of operations, and future SE products such as requirements and trade study tools, are being 
developed to coordinate with emerging exploration class vehicles and habitats. 


VIII. Future Work 


The ExMC SE team will continuing iterating with stakeholders on needs, goals, and high-level behaviors, and 
progress to define system measures of effectiveness and performance. The team will continue the analysis of 
behavioral content to define requirements and iterate on architecture. The suite of tools to support exploration 
system trade study analyses will be architected and development of those tools will be undertaken. The team expects 
increasing integration efforts with those undertaking work on other areas of the Crew Health and Performance 
System, and the broader exploration habitat and mission development. 
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IX. Conclusion 


A strong systems engineering foundation to support medical system definition and analyses that will inform 
research activity needs and prioritization has been established. Key stakeholders have been identified and engaged to 
understand their needs. Medical system behavioral content has been created to inform initial architecture 
development. A Model-Based Systems Engineering approach has been put in place to enable effective 
communication and coordination with exploration system maturation. 
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